對供應鏈管理的看法 （四）

首先，感謝各位朋友的關心，但是我比較期望的是透過提出我的看法，能夠跟各位交流，不要只按個「讚」啦！

第二，有時候在高鐵上還是想看小說就好，不會每天寫這些東西啦！

廢話少說，這次來聊聊我對建置APS的看法，但是我覺得以下這一段非常危險，可能要列為限制級。乾脆加上「本文為虛構，如有雷同，純屬巧合」比較好，哈哈。

其實客戶決定用APS時，我看過兩種情境：

情境一：依稀之間，覺得好像有那麼一些些需要，但是不清楚APS能做什麼，然後在APS vendor的遊說下（比較時髦的用語叫做：忽悠），決定用APS。有時候，甚至是因為資訊部門需要績效，所以硬叫規劃單位來搞個專案。

情境二：業務單位非常確定需求是什麼，但是對APS能做到怎麼樣還不清楚，然後在好多輪的簡報、demo、POC...等等之下，選了忽悠最好的廠商。

情境二是比較少見，不過不管是一或二，兩種情境都有一個共通點：對APS功能不熟悉。所以雙方就在不怎麼互相了解的情況下要開始專案了。然後就可以看到使用者非常有創新能力的開始想像未來該如何如何來用這套系統（開始構思原子小金剛的設計）。如果加上前面有個「顧問」公司幫客戶進行「業務流程改善」(BPR, business process re-engineering)，可以看到整個創新能力真是令人刮目相看，由原子小金剛變成無敵鐵金剛的設計了。

然後APS建置團隊就在水深火熱之中，與function gap來奮鬥，嘗試建造這尊無敵鐵金剛。姑且不談是不是建出無敵鐵金剛，通常使用者後來就發現，他要的只是一台腳踏車，讓他由走路變成騎腳踏車（而且還要一些時間才學的會騎車）。因此這座打造出來的「無敵鐵金剛」就被束之高閣、打入冷宮。

所以我覺得一個成功的APS導入，使用者要好好想清楚真正的需求到底是什麼？然後怎麼透過系統來幫助達到這樣的需求。而且滿足需求都是會付出一些代價的，例如：提供一些資料、規範一些作業程序、定義一些作業規則；而且這些東西都需要一直更新的，不是一次做好就結束了。整個走一次，才能確認需求在哪裡。

需求訂出來，並不就這麼結束了；接下來應該還要定義出如何衡量成績的具體指標，並進行business case的分析。例如：常常說導了這種系統會提高OTD (on-time delivery)，那應該看看目前是多少，然後目標會是多少，其中的效益會是怎樣？如此一來才能讓專案與實際績效連接在一起。不過另一個事實是，改善並不是單一原因造成的，例如：OTD提昇，是真的系統的效益？還是營運長最近盯的比較兇？不過，透過一些績效衡量的分析，讓使用者詳細檢視他所提出來的需求、想達到的業務目標，是一個好的作法。

(待續)